Streaming media transmissions involve the transmission of sound and pictures over the Internet in a streaming or continuous manner using data packets. The most effective manner of receiving streaming media requires some form of broadband technology such as a cable modem or digital subscriber line (DSL). Typical streaming media transmissions generally involve conventional client-server models.
FIG. 1 shows a typical client-server model and illustrates conventional client-server communications. In a streaming media session, a streaming client typically assumes that it is communicating with a single server, as is shown in FIG. 1 (see arrows illustrating a request for and delivery of data from client to server). Nevertheless, media delivery infrastructures have evolved from single server solutions to include delivery infrastructure that incorporate multiple distributed servers in the form of overlay networks such as that shown in FIG. 2.
The servers or nodes in the overlay network provide functionality that enhances the delivery of Web and streaming media. However, conventional systems that employ the overlay architecture have two important limitations. First, they typically exploit only the caching capabilities of the overlay nodes. Second, explicit client involvement may be required in realizing such caching capabilities. One example of overlay caching is Content Distribution Networks (CDN) whose operations are shown in FIG. 2. In a CDN, content are replicated a priori in multiple overlay nodes so that a client can access content from a closer overlay node than the original server.
Another common example of overlay caching is Web caching. Web caching differs from a CDN in that contents are delivered to a Web cache on-demand, rather than a priori for a CDN. Current versions of Netscape™ and Internet Explorer™ Web browsers have support for proxy configuration which allows all Web traffic to be directed to a specified Web cache. This functionality reduces the total amount of network traffic that is in motion and improves the response time of these browsers. Nevertheless, the above proxy solution requires explicit proxy support on the part of the application and knowledge to properly configure the proxy on the part of the user. As a result, default mechanisms for redirecting Web traffic to Web caches continue to be needed for mis-configured browsers and browsers that lack proxy support.
An existing solution to eliminate client involvement in a Web-caching context includes the Web Cache Communication Protocol (WCCP), which is supported by a number of existing routers. Specifically, through WCCP, routers can selectively or completely redirect Web or hypertext transfer protocol (HTTP) traffic to specified Web caches.
FIG. 3 illustrates the operation of a WCCP enabled router. Referring to FIG. 3, where a browser client B requests content from server S, a WCCP enabled router R located in a path between B and S is configured to redirect all HTTP traffic to a Web cache C. In this way, B can obtain a desired piece of content from C (a more efficient place from which to receive the content) despite the fact that the request is directed to S. The client B thinks it is communicating with server S when the data is actually served from Web cache C. Since client B is unaware of the caching mechanism, the procedure is client-transparent. In contrast, a solution involving setting a proxy in the client is not client-transparent since the client is explicitly instructed to contact a cache.
Besides the WCCP, there are a number of other mechanisms that are utilized to effect a redirection of client requests to appropriate servers. A common technique is based on modifications of the Internet Domain Name Service (DNS) and does not assume the existence of router support.
It should be appreciated that simple access to Web pages typically consists of two steps: (1) a client's request, (2) followed by a server's transmission of requested data, as is illustrated in FIGS. 1 and 2. However, accesses to streaming media content typically involve many more steps. Several industrial alliances and working groups have proposed the use of a lightweight protocol for streaming media session control to be employed alongside a separate protocol for delivery of the media data itself.
In one such formulation the real time streaming protocol (RTSP) and the real time transport protocol (RTP) are used in conjunction, for media session control, and media data delivery, respectively. A typical session is illustrated in FIG. 4.
Referring to FIG. 4, the initial step in such processes, which entails a querying of server capability, is optional. However, steps 2 and 3 are generally performed between a streaming client and server before a play request is issued and content streaming commences.
At step 2 of FIG. 4, a description of the requested content is returned to the requesting client. The description serves as a menu of the available streams, e.g., a specification of the audio and video streams that are available in different formats. In addition to format information about each stream, network information about how to access the individual streams is also provided. And, at step 3, the client chooses from the menu of available streams a desired set of streams before issuing a play request to effect a transfer of the selected streams at step 4.
Each of the aforementioned techniques addresses only the initial redirection of requests to locations that are known a priori. Moreover, neither of the systems described have the capacity to dynamically reconfigure itself to address the service needs of different media streams in a streaming media content.